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R marks 

Claims 1-4 are pending in this application. No claims have been amended. No 
claims have been added or cancelled. 



The Office Action has rejected claims 1-4 under 35 U.S.C. § 103(a) as being 
unpatentable over Beausoleil et al., U.S. Patent No. 5,551 ,013 (hereinafter "Beausoleil") 
in view of Austin et al., U.S. Patent No. 4,885,684 (hereinafter "Austin") and further in 
view of Baker et al., U.S. Patent No. 5,701 ,502 (hereinafter "Baker). Applicants 
respectfully traverse this rejection. 

"To establish a prima facie case of obviousness, three basic criteria must be met. 
First, there must be some suggestion or motivation, either in the references themselves 
or in the knowledge generally available to one of ordinary skill in the art, to modify the 
reference or to combine reference teachings. Second, there must be a reasonable 
expectation of success. Finally, the prior art reference (or references when combined) 
must teach or suggest all the claim limitations." MPEP 2143. As explained below, 
neither Beausoleil, Austin nor Baker teach or suggest all of limitations of Claim 1 and 
there is no suggestion or motivation to combine Beausoleil with Austin and/or Baker. 



Beausoleil does not teach or suggest "blocking codes" that cause "transfers 
between the plurality of module processors and said module main memory" to be 
blocked as recited in Claim 1 . The Office Action asserts that Beausoleil discloses this 
limitation relying on two portions of the specification. The Office Action first cites to the 
"Control Store" section of Beausoleil. See 12/31/03 Office Action at 3 (citing to Col. 5, 
line 39 to col. 6, line 18); see also 12/21/03 Office Action at 7 (stating "From the 
rejection, the bits being decoded and being used to allow whether or not memory 
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operations are enabled are meeting what is interpreted as blocking code."). This 
section describes a memory operation bit (MOP) that is included in a control word. 
Beausoleil teaches that if the MOP bit in the control word is "inactive (off)", it signals a 
logic function emulation operation. If the MOP bit in the control word is "active (on)", it 
signals a memory operation. Col. 6, II. 14-35. In other words, this MOP bit controls 
whether the processors will emulate a logic function operation or a memory array 
operation during execution of that particular control word. This MOP bit is not a 
"blocking codeQ" that causes "transfers between the plurality of module processors and 
said module main memory" to be blocked as recited in Claim 1 . 

The Office Action also cites to Col. 10, line 64 to Col. 1 1 , line 2 of Beausoleil. All 
this section states, however, is that the user's design is compiled into a series of control 
words. Beausoleil, however, discloses nothing about the insertion of blocking codes, 
which by definition are not part of a user's design. 

Austin does not teach or suggest "blocking codes" that cause "transfers between 
the plurality of module processors and said module main memory" to be blocked. The 
Office Action appears to concede this since it merely relies on Austin for the teaching of 
a maintenance bus. See 12/21/03 Office Action at 7 ('What is not explicitly disclosed in 
Beausoleil has been provided by Austin, and that is the use of maintenance facilities 
(bus) to effect fault-prevention and error recovery of modules under execution."). 

Likewise, Baker does not teach or suggest "blocking codes" that cause "transfers 
between the plurality of module processors and said module main memory" to be 
blocked. The portions of the Baker specification cited in the Office Action (Col. 119, 
lines 4-53; col. 127, lines 3-23) describe a resynchronization process for two or more 
processors that occurs when there is an initial power on, the appearance of a new 
processor, or a recovery from an error condition. Nothing in these portions of Baker 
teach or suggest "blocking codes" that cause "transfers between the plurality of module 
processors and said module main memory" to be blocked. 

Moreover, neither Beausoleil, Austin nor Baker teach or suggest how data is 
blocked and data is transferred as required by Claim 1 . Claim 1 requires that the 
blocking code be decoded. Once the blocking code is decoded, Claim 1 requires that 
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"transfers between the plurality of module processors and said module main memory" 
be blocked and that data be transferred while the blocking condition exists. Neither 
Austin, Beausoleil nor Baker teach or suggest this. In particular, Austin neither teaches 
nor suggests decoding in response to decoding blocking code. First, as discussed, 
Austin does not even teach a blocking code, meaning that Austin cannot teach 
decoding such a code. Moreover, the sections from Austin relied upon in the Office 
Action make no such teachings. In particular, the discussion at columns 6 and 7 in 
Austin only discuss management of the computer system disclosed therein. There is no 
discussion of disabling memory activities while they are updated. The same is true for 
the discussion at columns 12-13 in Austin. Col. 12, line 47 through Col. 13, line 7 relate 
to error correction and fault tolerance. This discussion says nothing about blocking 
codes that disable main data memories while they are updated. 



Like the present invention, Beausoleil relates to the emulation of integrated circuit 
designs. Austin and Baker relate to completely different technologies. Austin relates to 
a distributed data processing network, which has nothing to do with the emulation of 
integrated circuit designs. See, e.g., Cols. 1-3. Similarly, Baker relates fault-tolerant 
mainframe computer systems, which has nothing to do with the emulation of integrated 
circuit designs. See, e.g., Col. 7, lines 33-38 ("Accordingly, it is intended that the 
present improvement will provide a fault tolerant environment and architecture for a 
normally non-fault-tolerant processing system and operating system without major 
rewrite of the operating system. In the preferred embodiment a model of IBM 
System/88 is coupled to a model of an IBM S/370."). 

There is simply no suggestion or motivation in any of these references to 
combine the references with one another. See MPEP 2143. Furthermore, one of 
ordinary skill in the art would not look to combine Austin or Baker with Beausoleil since 
each reference relates to unrelated areas of technology. 



There Is No Motivation Or Suggestion To Combine The References 
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D p nd nt Claims 2-4 

The foregoing arguments apply to Claims 2-4, as they all are dependent on claim 1 . 
Therefore, Applicants respectfully submit that claims 2-4 are allowable as well. 



For the foregoing reasons, the Office Action has failed to establish a prima facie 
case of obviousness under 35 U.S.C. § 103. See MPEP 2143. Therefore, Applicants 
respectfully submit that this application is in condition for allowance, which is 
respectfully requested. Should the Examiner have any questions or comments on the 
application, the Examiner should feel free to contact the undersigned via telephone. 

The Commissioner is authorized to charge any fee which may be required in 
connection with this Amendment to deposit account No. 15-0665. 



Orrick, Herrington & Sutcliffe LLP 
4 Park Plaza, Suite 1600 
Irvine, CA 92614-2558 
Tel. 650-614-7622 
Fax: 949-567-6710 



Conclusion 



Respectfully submitted, 

ORRICK, HERRINGTON & SUTCLIFFE LLP 



Dated: April 30, 2004 




Todd M. Briggs 
Reg. No. 44,040 



